-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manage the ignition stub config #1792
Conversation
84d9b4c
to
bcfe84b
Compare
/retest |
/retest |
This works as expected, both alone and with openshift/installer#3730
The new user-data is created just fine from the MCO and read correctly by machine(sets) in MAO. If you create a cluster with both this PR and openshift/installer#3730 you'll get a fully functional cluster using the new managed-by-MCO user-data:
same for machinesets Scaling up the worker machinesets works as expected as well I'm going to create create the enhacement and cleanup both PRs - the MCO PR has to go in first ofc. |
af1e238
to
998e52d
Compare
have just confirmed on an upgraded cluster that we effectively re-generate what the installer generates so it's safe to assume we'll generate the correct ign v3 version once we upgrade 💪 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks sane to me!
4b9b879
to
5141800
Compare
yeah, in the upgrade scenarios this is gonna be a no-op for all 4.6-dev as machines still points to the old userdata name. When 4.6 goes out (upgrade scenario) we simply create the new userdata secret which users can manually use in machinesets and we can leverage to be used in a future update-bootimages feature. In the installation case it's the same as we won't be using this until installer switches naming as well does it make sense? 🤔
|
11d9ba2
to
3eb7839
Compare
I've pushed a change to allow the creation of the userdata for every pool in the cluster (which I still think it's correct as Michael pointed out in the enhancement) - it shouldn't be disruptive, we just do what we always had to do 🤷♂️ I'll test this out again and report back quickly:
it works for me 👍 |
/skip |
/retest |
With this we let the installer take care of installing the initial user-data secret and we then take over with our managed secret. if we are upgrading (and thus no installer at play), we just create the new (managed) secret. Signed-off-by: Antonio Murdaca <[email protected]>
/retest |
1 similar comment
/retest |
/skip |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, runcom, yuqi-zhang The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest Please review the full test history for this PR and help us cut down flakes. |
@runcom: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
/test e2e-gcp-upgrade |
/retest Please review the full test history for this PR and help us cut down flakes. |
Signed-off-by: Antonio Murdaca <[email protected]>
Bug 1881703: Revert #1792
Nothing to see here yet, just code, and testing going on elsewherecurrent testing planinstall with this PR (covered in CI)upgrade to this PR (covered in CI)test an install with Have the MCO manage the ignition stub config installer#3730test and upgrade with the aboveRelated issue #683
Enhancement openshift/enhancements#368
The key points here are:
What this PR does is basically:
Signed-off-by: Antonio Murdaca [email protected]